home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1989 / Jul 89 / W0026-MacApp memory Manag-Jul89 < prev    next >
Encoding:
Text File  |  1991-03-06  |  3.0 KB  |  81 lines  |  [TEXT/GEOL]
  1. Item    6388772                         8-July-89        00:33
  2.  
  3. From:   D2215                           Dac SW, Wilma Blair, PRT
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. cc:     MACDTS                          Macintosh Developer Technical Supt.
  8.  
  9. Sub:    MacApp memory Managment
  10.  
  11. I am attempting outline a strategy for handling low memory conditions.
  12.  
  13. A new global function would be added:
  14.  
  15. FUNCTION NewTemplateWindowMemCheck (viewRsrcId: INTEGER; itsDocument:
  16. TDocument): TWindow;
  17. BEGIN
  18.     WHILE MemSpaceIsLow DO
  19.       IF NOT gApplication.FreeNonCriticalMemory THEN Failure (memFullErr, );
  20.     NewTemplateWindowMemCheck:= NewTemplateWindow (viewRsrcId, itsDocument);
  21.    WHILE MemSpaceIsLow DO
  22.       IF NOT gApplication.FreeNonCriticalMemory THEN Failure (memFullErr, );
  23. END;
  24.  
  25. TApplication.FreeNonCriticalMemory: BOOLEAN; would default to false and would
  26. be overriden to return true if the application could free some permanent
  27. memory.
  28.  
  29. In my application, once a view is created, I keep it around as the user may
  30. wish to open that window at a later time (faster to open a view than to create
  31. and initialize one).  Such non-displayed views could be freed if a user request
  32. needed more memory so I would have FreeNonCriticalMemory free a view at a time
  33. until enough memory was available.
  34.  
  35. Does this seem to be a workable strategy?
  36.  
  37. In another situation, when creating an indeterminate number of objects and
  38. adding them to a TList (could be several thousand), I dont wish to call
  39. FailSpaceIsLow before adding each object as this could slow things down quite a
  40. bit.
  41.  
  42. It would be preferable to store how much permanent memory was available before
  43. any objects were created in a variable and decrement this variable by the size
  44. of the object plus a fixed overhead (for object handle and the list, say 12
  45. bytes) before creating each object.  I could get the amount of permanent memory
  46. available by the following code fragment used by the debugger:
  47.  
  48. oldPerm := PermAllocation(true);
  49.             memSpace := FreeMem;
  50.             oldPerm := PermAllocation(oldPerm);
  51.  
  52. Is this workable?
  53.  
  54. I am a little unclear about what the debugger reports with the Heap Inspect
  55. command.  The only docs I have on the MacApp memory management mechanism came
  56. in the Macapp 1.1 newsFlash and they seem to give contradictory information.
  57.  
  58. Under the "High Water Mark" heading,  it states that
  59.  
  60. ...the "extra" is the sum of the sizes of objects you've allocated ... you can
  61. use "extra" to reserve more temporary memory...
  62.  
  63. I though that the objects you allocated used permanent memory?
  64.  
  65. I don't understand what the debugger items under TEMP SPACE (current temp
  66. space: locked, unlocked, total, purgeable) mean and how to use them.
  67.  
  68. CheckReserves is only called at one place in MacApp.  How should this be used?
  69.  
  70. Could the forthcoming memory management docs for 2.0b9 (hopefully more clear)
  71. be posted to AppleLink?
  72.  
  73. Also, using the debugger (Heap Show), I see that many of my segments that I
  74. know were never called are loaded (but not resident).  I don't understand why
  75. they are loaded?
  76.  
  77. Regards, Les Caudle
  78.  
  79.  
  80.  
  81.